Data is frequently transferred over public networks, in which other users of the network have access to the transferred data. These public networks have become ubiquitous with the explosion of Internet-enabled devices. However, data transferred over public networks may often include sensitive data not intended for viewing by a user other than the recipient. Furthermore, the user may specifically desire to prevent other users from viewing the data. Thus, secure connections may be created over the public networks. The secure connections may encrypt the data to ensure that only the intended recipient may view the data. Secure connections may be established through a secure sockets layer/transport layer security (SSL/TLS) protocol with the aid of a certificate. The server communicating with the client may have a SSL/TLS certificate that provides the client with an assurance that the server is the computer the server claims to be. Furthermore, the certificate may include the public key for use by the client to transmit encrypted data to the server.
The server receiving the connection may also request that the client prove its identity by supplying a certificate.
A SSL/TLS connection cannot be established between two systems, such as a server and a client, without the exchange of the certificate. In order for the connection to he secure, the system that receives the certificate, such as a client, must check whether the certificate is valid. To determine if the certificate is valid, the client system may compare the certificate to a saved list of certificates stored in the client system that were predefined as trusted. Many computer systems will not allow an SSL/TLS connection while acting as a client if the received certificate is not trusted.
Conventionally, many users of client computers use terminal emulation, such as software that runs on the client computer and emulates terminal protocols used by the server. The terminal emulation software is set up to communicate with the server, which prompts the user at the client computer to enter a userid/password to establish his identity. In the usual case, the user will already have established his identity to the client computer. This could be done by supplying a userid and password when logging onto the client computer, or by use of a smart card, such as a Common Access Card (CAC) or by the use of multi-factor authentication, such as supplying a smart card and a corresponding PIN. Having to manually enter a userid and password to connect with the server, after already establishing the user's identity for the client computer, is an inconvenience at best, and if the user needs to establish connections with several different servers, separate manual logons can lead to a proliferation of userid/password combinations, increasing the likelihood of the user's credentials being discovered and misused by someone else.
Single sign-on solutions enable a user at a client workstation to connect to multiple servers without separately supplying credentials when establishing the connections. For example, Kerberos is one such solution. NTLM is another example. In each of those single sign-on solutions, separate external authentication processors are required for processing the Kerberos or NTLM requests and storing authentication information. For some environments, the complexity of deploying Kerberos is prohibitive. Furthermore, in some environments, the requirement to have additional authentication servers for Kerberos or NTLM makes them unacceptable solutions. This disclosure describes a single sign-on solution that does not require an external authentication server.